home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / sys / amiga / applications / 2543 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  3.8 KB
  1. Path: soap.news.pipex.net!pipex!usenet
  2. From: m.hendry@dial.pipex.com (Mathew Hendry)
  3. Newsgroups: comp.sys.amiga.applications
  4. Subject: Executive and screen blankers (was Re: Executive and AmiTCP..)
  5. Date: Tue, 27 Feb 96 19:00:52
  6. Organization: Private node.
  7. Distribution: world
  8. Message-ID: <19960227.41C5A0.1156B@an052.du.pipex.com>
  9. References: <4gv6l6$qb6@walrus.megabaud.fi>
  10. NNTP-Posting-Host: an052.du.pipex.com
  11. X-Newsreader: TIN [AMIGA 1.3 950726BETA PL0]
  12.  
  13. Petri Nordlund (petrin@walrus.megabaud.fi) wrote:
  14. : Mathew Hendry (m.hendry@dial.pipex.com) writes:
  15. : >The only way to fix it completely would be to add a capability to BlitzBlank
  16. : >to keep an eye on Executive's CPU load stats, so that it could switch to
  17. : >another blanking method which consumes less or no CPU time when the total
  18. : >CPU load reaches a preset threshold. BlitzBlank does have its own "Watch CPU"
  19. : >option, but it doesn't work properly when Executive is running.
  20. : 
  21. :   The best solution would be to run the blanker in a totally separate
  22. :   task at low priority (below Executive's catch range) and have another
  23. :   task watching for mouse movement and keyboard, so the screen could
  24. :   be easily unblanked (the blanker task's priority has to be first
  25. :   raised so it will get CPU time to close it's screen).
  26.  
  27. That's basically what BlitzBlank does. The main BlitzBlank task, which detects
  28. mouse and keyboard activity, runs at priority 10, well above the catch range.
  29. When the screen is blanked, two new tasks appear - BB.Module and BB.WatchTask,
  30. at the same priority as each other (-5 is the recommended value). If
  31. BB.WatchTask is getting no CPU time (I'm not sure how the BlitzBlank task
  32. recognises this - I am guessing that it is some sort of message-based system,
  33. i.e. if BB.WatchTask does not repond to a message quickly enough, it is
  34. assumed to be getting no CPU), BB.Module is stopped and replaced with a blank
  35. screen.
  36.  
  37. Such a method doesn't work with Executive running, of course, because all
  38. sheduled tasks are given CPU time. If BB.WatchTask was removed and BlitzBlank
  39. instead kept an eye on Executive's CPU load stats, things would work fine.
  40.  
  41. With such a system, there would be no need to place the blanker module below
  42. the catch range, since it would automatically be stopped when the load
  43. increased. And, being within the catch range, it would have access to the CPU
  44. in order to stop itself. Temporarily raising the priority of BB.Module _above_
  45. the catch range would allow it to respond more quickly - its priority should
  46. be raised similarly when an input event occurs.
  47.  
  48. Specifically:
  49.  
  50. if(total_load() > 1) {
  51.   open_black_screen();
  52.   set_priority(BB.Module, above_catch_range);
  53.   stop_module(BB.Module);
  54. }
  55.  
  56. will stop the blanker module as soon as all available CPU time is being consumed,
  57. Until the total load reaches 1, there is no need to stop the module.
  58.  
  59. Deciding when to start up the blanker module again would be more difficult. I
  60. can't think of a reliable test for this offhand.
  61.  
  62. Perhaps:
  63.  
  64. if(total_load() + lastload(BB.Module) <= 1) {
  65.   start_module(BB.Module);
  66.   close_black_screen();
  67. }
  68.  
  69. lastload(BB.Module) being the load BB.Module was producing just before it was
  70. stopped by the previous routine. The problem is that this assumes that the
  71. module will produce the same load each time it is run. That may not be true.
  72. It could also be deceived if the load decreases temporarily, for example
  73. during disk access to load / save new data.
  74.  
  75. (Actually, come to think of it, the first routine could be misled in a similar
  76. way, but this would not be an error which harmed the performance of other
  77. applications).
  78.  
  79. It might just be easier to leave the black screen open until the screen is
  80. unblanked by the user. That would also stop the blanker from continually
  81. flipping between a black screen and a graphical module as the load fluctuates.
  82.  
  83. -- Mat.
  84.